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(57) Abstract 

A system and method for receiving wireless information on a portable computing device (10) includes powering a wireless receiver 
(27) only from a battery (37) of the portable computing device (10). Receiving wireless information and storing the wireless information 
in memory (64) of the wireless receiver (27). The wireless receiver (27) wakes up a processor (20) of die portable computing device (10) 
when the wireless information fills a threshold of the memory available in the wireless receiver (27). The wireless information is then 
transferred from the memory (64) of the wireless receiver to the memory (18) of the portable computing device (10). 
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SYSTEM AND METHOD FOR RECEIVING WIRELESS 
INFORMATION ON A MOBILE DEVICE 

BACKGROUND OF THE INVENTION 
The present invention relates to personal 
5 mobile computing devices commonly known as handheld 
portable computers. More particularly, the present 
invention relates to a system and method for receiving 
wireless information on a mobile device. 

Mobile devices are small electronic 

10 computing devices often referred to as personal 
digital assistants. Many of such mobile devices are 
handheld devices, or palm- size devices, which 
comfortably fit within the hand. One commercially 
available mobile device is sold under the trade name 

15 HandHeld PC (or H/PC) having software provided by 
Microsoft Corporation of Redmond, Washington. 

Generally, the mobile device includes a 
processor, random access memory (RAM) , and an input 
device such as a keyboard and a display, wherein the 

20 keyboard can be integrated with the display, such as a 
touch sensitive display. A communication interface is 
optionally provided and is commonly used to 
communicate with a desktop computer. A replaceable or 
rechargeable battery powers the mobile device. 

25 Optionally, the mobile device can receive power from 
an external power source that overrides or recharges 
the built-in battery, such as a suitable AC or DC 
adapter, or a powered docking cradle. 

In one common application, the mobile device 

3 0 is used in conjunction with the desktop computer. For 
example, the user of the mobile device may also have 
access to, and use, a desktop computer at work or at 
home. The user typically runs the same types of 
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applications on botn the desktop computer and on the 
mobile device. Thus, it is quite advantageous for the 
mobile device to be designed to be coupled to the 
desktop computer to exchange information with, and 

5 share information with, the mobile device. 

Another technique for providing information 
to the mobile device is described in the above - 
identified co-pending U.S. patent applications. 
Generally, the method and system described therein 

0 allow the mobile device to receive information over a 
wireless, low bit-rate channel or transport, such as a 
pager network. For example, such information can 
include electronic mail or news, weather, sports, 
traffic and local event information typically obtained 

5 from a desktop computer connected to the Internet. 

However, the limited battery power available 
on the mobile device can present significant obstacles 
in transferring information using the wireless low 
bit-rate channel. For example, the mobile device 

0 should be able to receive information over the 
wireless transport at any time. However, if the mobile 
device was merely left on, awaiting information to be 
received, the battery for the mobile device would be 
quickly depleted. This method of operation would 

5 require the user to constantly recharge or replace the 
battery. 

Alternatively, a wireless receiver on the 
mobile device can turn on the mobile device when it 
detects that information is being sent to the mobile 
0 device. However, if large amounts of information are 
being transmitted over the wireless transport, . the 
wireless receiver can turn on the mobile device so 
often that again the battery for the mobile device can 
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be quickly depleted. 

Another drawback of most wireless receivers 
for a mobile device is that the wireless receiver 
requires its own battery, separate from the battery 
5 used on the mobile device since the mobile device can 
be turned off at any time. This increases the size, 
weight and cost of the wireless receiver as well as 
complicates use for the user since he must maintain 
both batteries. 

10 There is a continuing need to improve 

wireless communication with a mobile device. In 
particular, there is a need to efficiently process 
information transmitted over a wireless channel to the 
mobile device in order to conserve battery resources 

15 on the mobile device. 

SUMMARY OF THE INVENTION 
A system and method for receiving wireless 
information on a portable computing device includes 
powering a wireless receiver only from a battery of 

2 0 the portable computing device. Receiving wireless 

information and storing the wireless information in 
memory of the wireless receiver. The wireless receiver 
wakes up a processor of the portable computing device 
when the wireless information fills a threshold of the 
25 memory available in the wireless receiver. The 
wireless information is then transferred from the 
memory of the wireless receiver to the memory of the 
portable computing device. 

Another aspect of the present invention is a 

3 0 wireless receiver for use in a portable computing 

device. The wireless receiver includes a radio 
receiver for receiving wireless information, memory 
for storing the wireless information and a processor 
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for analyzing the wireless information. The radio 
receiver, the memory and the processor are powered 
only from the portable computing device. 

Another aspect of the present invention 
5 includes a method for receiving wireless information 
on a portable computing device, wherein the wireless 
information is transmitted to the portable computing 
device with respect to wireless addresses. The method 
includes providing a list of wireless addresses on the 

10 portable computing device. Each wireless address 
corresponds to selected information to be received. 
Each wireless address also includes an associated 
status entry indicating enablement of the wireless 
address . The method further includes selectively 

15 enabling and .disabling the status entry for the 
wireless address to . allow receipt of the corresponding 
information as a function of an operating parameter of 
the device. In one exemplary embodiment, the operating 
parameter indicates when the portable computing device 

2 0 is being powered or connected to an external source 

such as a power docking cradle . 

BRIEF DESCRIPTION OF THE DRAWINGS 
FIG. 1 is a simplified block diagram 
illustrating one embodiment of a mobile device in 
25 accordance with the present invention. 

FIG. 2 is a more detailed block diagram of 
one embodiment of the mobile device shown in FIG. 1. 

FIG. 3 is a simplified pictorial 
illustration of one embodiment of the mobile device in 

3 0 accordance with the present invention. 

FIG. 4 is a simplified pictorial 
illustration of another embodiment of the mobile 
device in accordance with the present invention. 
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FIG. 5 is a simplified schematic 
illustration of a wireless receiver in accordance with 
the present invention. 

FIG. 6 is a flow chart illustrating a method 
5 of operation for the wireless receiver and the mobile 
device . 

FIG. 7 illustrates a detailed flow chart 
illustrating operation of the wireless receiver and 
the mobile device. 

10 FIG. 8 is a pictorial representation of a 

list of wireless addresses. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

FIG. 1 is a block diagram of an exemplary- 
portable computing device, herein a mobile device 10 

15 in accordance with the present invention. FIG. 1 
illustrates that, in one preferred embodiment, the 
mobile device 10 is suitable for connection with, and 
to receive information from, a desktop computer 12, a 
wireless transport 14, or both. The wireless transport 

2 0 14 can be a paging network, cellular digital packet 
data (CDPD) , FM-sideband, or other suitable wireless 
communications. However, it should also be noted that 
the mobile device 10 may not be equipped to be 
connected to the desktop computer 12' , and the present 

25 invention applies regardless of whether the mobile 
device 10 is provided with this capability. 

In any case, the mobile device 10 preferably 
includes one or more application programs 16 and an 
object store 18. The application programs 16 can be, 

30 for example, a personal information manager (PIM) 16A 
that stores objects related to a user's electronic 
mail (e-mail) and scheduling or calendaring 
information- The application programs 16 can also 
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include a content viewer 16B that is used to view 
information obtained from a wide-area network (WAN) , 
such as the Internet. In one embodiment, the content 
viewer 16B is an "offline" viewer in that information 
5 is stored primarily before viewing, wherein the user 
does not interact with the source of information in 
real time. However, it should be understood that the 
present invention can be implemented in a real time 
environment wherein the wireless transport 14 provides 

10 two-way communication. 

The wireless transport 14 is used to send 
information to the mobile device 10 for storage in the 
object store 18 and for use by the application 
programs 16. The wireless transport 14 receives the 

15 information to be sent from an information source 
provider 13, which, for example, can be a source of 
news, weather, sports, traffic or local event 
information. Likewise, the information source provider 
13 can receive e-mail and/or scheduling information 

20 from the desktop computer 12 to be transmitted to the 
mobile device 10 through the wireless transport 14. 
The information from the desktop computer 12 can be 
supplied to the information source provider 13 through 
any suitable communication link, such as a direct 

2 5 modem connection. In another embodiment, the desktop 
computer 12 and the information source provider 13 can 
be connected together forming a local area network 
(LAN) or a wide area network (WAN) . Such networking 
environments are commonplace in offices, enterprise- 

30 wide computer network Intranets and the Internet. If 
desired, the desktop computer 12 can also be directly 
connected to the wireless transport 14 . 

The object store 18 is preferably configured 
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to store a plurality of individual records or objects, 
each comprising a plurality of fields or properties 
related to features of PIM 16A, or to data viewable on 
the content viewer 16B. For example, where PIM ISA is 
5 an e-mail and scheduling program, object store 18 is 
configured to store objects, each of which has a 
plurality of properties which can be associated with 
e-mail, scheduling or calendaring features provided by 
PIM 16A. 

10 It is also worth noting that, in one. 

" embodiment, the mobile device 10 can be coupled to the 
desktop computer 12 using any suitable, and 
commercially available, communication link and using a 
suitable communications protocol. For instance, in one 

15 embodiment, the mobile device 10 communicates with the 
desktop computer 12 with a physical cable which 
communicates using a serial communications protocol. 
Other communication mechanisms include infra-red (IR) 
communication and direct modem communication. 

2 0 It is also worth noting that the mobile 

device 10, in one embodiment, can be synchronized with 
the desktop computer 12. In that instance, properties 
of objects stored in object store 18 are similar to 
properties of other instances of the same objects 
25 stored in the object store 18 on the desktop computer 
12 or on the mobile device 14. Thus, for example,, when 
one instance of an object stored in the object store 
18 on the desktop computer 12, the second instance of 
that object in the object store 18 of the mobile 

3 0 device 10 is updated the next time the mobile device 

10 is connected to the desktop computer 12 so that 
both instances of the same object contain up-to-date 
data. This is commonly referred to as synchronization. 
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In order to accomplish synchronization, 
synchronization components run on both the mobile 
device 10 and the desktop computer 12 . The 
synchronization components communicate with one 
5 another through well defined interfaces to manage 
communication and synchronization. 

FIG. 2 is a more detailed block diagram of 
the mobile device 10. The mobile device 10 includes a 
processor 20, memory 22 , input/output (I/O) components 
10 24, a desktop computer communication interface 26 and 
a wireless receiver 27. In a preferred embodiment, 
these components of the mobile device 10 are coupled 
for communication with one another over a suitable bus 
28 . 

15 Memory 22 is preferably implemented as non- 

volatile electronic memory such as random access 
memory (RAM) with a battery back-up module (not shown) 
such that information stored in memory 22 is not lost 
when the general power to the mobile device 10 is shut 

20 down. A portion of memory 22 "is preferably allocated 
as addressable memory for program execution, while the 
remaining portion of memory 22 is preferably used for 
storage, such as to simulate storage on a disk drive. 

Memory 22 includes an operating system 30, 

25 the application programs 16 (such as PIM 16A discussed 
with respect to FIG. 1) , as well as the object store 
18. During operation, the operating system 30 is 
preferably loaded into, and executed by, the processor 
20 from memory 22. The operating system 30, in one 

30 preferred embodiment,, is a "WINDOWS CE" brand 
operating system commercially available from Microsoft 
Corporation. The operating system 30 is preferably 
designed for mobile devices, and implements features 
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which can be utilized by PIM 16A and content viewer 
16B through a set of exposed application programming 
interfaces and methods. The objects in object store 18 
are preferably maintained by PIM 16A, content viewer 
5 16B and the operating system 30, at least partially in 
response to calls to the exposed application 
programming interfaces and methods . 

The I/O components 24, in one preferred 
embodiment, are provided to facilitate input and 

10 output operations from the user of the mobile device 
10. The I/O components 24 are described in greater 
detail with respect to FIGS. 3 and 4. 

The desktop computer communication interface 
26 is optionally provided as any suitable, and 

15 commercially available, communication interface. The 
interface 26 is used to communicate with the desktop 
computer 12, as described with respect to FIG. 1. 

The wireless receiver 27 receives 
information from the information source provider 13 

20 and includes an antenna 31. The -wireless receiver 27 
is coupled to the bus 28 for communication with the 
processor 2 0 and the object store 18 to store 
information received from the wireless transport 14 in 
a manner described below. 

25 A power supply 35 includes a battery 37 for 

powering the mobile device 10. The power supply 35 
communicates with the processor 20 to control power 
provided to the above -de scribed components. One aspect 
of the present invention is that the power supply 35 

3 0 provides all power for the mobile device 10, including 
the wireless receiver 27 without the need for an 
external battery as typically found in the prior art . 
In a second aspect of the present invention, 
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components of the mobile device 10, such as the I/O 
components 24, are provided power only when necessary 
to process the incoming information. This aspect of 
the present invention is discussed below in greater 
detail. 

Optionally, the mobile device 10 can receive 
power from an external power source 41 that overrides 
or recharges the built-in battery 37. For instance, 
the external power source 41 can include a suitable AC 
or DC adapter, or a power docking cradle for the 
mobile device 10. 

FIG. 3 is a simplified pictorial 
illustration of one preferred embodiment of the mobile 
device 10 which can be used in accordance with the 
present invention. The mobile device 10, as 
illustrated in FIG. 3, can be a desktop assistant sold 
under the designation H/PC having software provided by 
the Microsoft Corporation. In one preferred 
embodiment, the mobile device 10 includes a 
miniaturized keyboard 32, a display 34 and a stylus 
36. In the embodiment shown in FIG. 3, the display 34 
is a liquid crystal display (LCD) which uses a contact- 
sensitive display screen in conjunction with the 
stylus 36. The stylus 36 is used to press or contact 
the display 34 at designated coordinates to accomplish 
certain user input functions. The miniaturized 
keyboard 32 is preferably implemented as a 
miniaturized alpha-numeric keyboard, with any suitable 
and desired function keys which are also provided for 
accomplishing certain user input functions. 

FIG. 4 is another simplified pictorial 
illustration of the mobile device 10 in accordance 
with another preferred embodiment of the present 
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invention. The mobile device 10, as illustrated in 
FIG. 4, includes some items which are similar to those 
described with respect to FIG. 3, and are similarly 
numbered. For instance, the mobile device 10, as shown 
5 in FIG. 4, also includes the touch sensitive display 
34 which can be used, in conjunction with the stylus 
36, to accomplish certain user input functions. It 
should be noted that the display 34 for the mobile 
device shown in FIGS. 3 and 4 can be the same size,, or 

10 of sizes, but will typically be much smaller than a 
conventional display used with a desktop computer. For 
example, the display 34 shown in FIGS. 3 and 4 may be 
defined by a matrix of only 240x320 coordinates, or 
160x160 coordinates, or any other suitable size. 

15 The mobile device 10 shown in FIG. 4 also 

includes a number of user input keys or buttons (such 
as .scroll buttons 38) which allow the user to scroll 
through menu options or other display options which 
are displayed on display 34, without contacting the 

20 display 34. In addition, the mobile device 10 shown in 
FIG . 4 also preferably includes a power button 4 0 
which can be used to turn on and off the general power 
to the mobile device 10. 

It should also be noted that in the 

25 embodiment illustrated in FIG. 4, the mobile device 10 
includes a handwriting area 42. Handwriting area 42 
can be used in conjunction with the stylus 3 6 such 
that the user can write messages which are stored in 
memory 22 for later use by the mobile device 10. In 

3 0 one preferred embodiment, the handwritten messages are 
simply stored in handwritten form and can be recalled 
by the user and displayed on the display 34 such that 
the user can review the handwritten messages entered 
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into the mobile device 10 . In another preferred 
embodiment, the mobile device 10 is provided with a 
character recognition module such that the user can 
enter alpha-numeric information into the mobile device 
5 10 by writing that alpha-numeric information on the 
area 42 with the stylus 36. In that instance, the 
character recognition module in the mobile device 10 
recognizes the alpha-numeric characters and converts 
the characters into computer recognizable alpha- 

10 numeric characters which can be used by the 
application programs 16 in the mobile device 10. 

Although illustrated in FIGS . 3 and 4 as a 
handheld portable computer, it should be understood 
that the present invention can be used in other forms 

15 of portable computing devices such as laptops, 
computers designed for use in automobiles, and 
portable phones having computers . 

FIG. 5 is a simplified diagram of the 
wireless receiver 27 as coupled to other components of 

20 the mobile device 10. Generally, information sent by 
the wireless transport 14 is detected by a RF receiver 
60 through the antenna 31. The RF receiver 60 provides 
the wireless information to a processor 62 . The 
processor 62 temporarily stores the information in 

25 suitable memory, forming, for example, a FIFO (first- 
in-first-out) buffer. The processor 62 and memory 64 
are operably coupled to an interface controller 66, 
which is commonly used to connect components to a 
computer system. In particular, the interface 

3 0 controller 66 couples the wireless receiver 2 7 to the 
bus 2 8 and to an interrupt controller 68 that is 
operably coupled to the processor 2 0 of the mobile 
device 10 . The interface controller 66 is designed and 
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operates according to known industry standards such as 
PCMCIA and Compact Flash Specifications. In one 
embodiment, the components of the wireless receiver 2 7 
form a removable card that can be selectively coupled 
5 to an expansion slot provided in the mobile device 10 
wherein suitable connectors are provided to couple the 
interface controller 66 to the bus 28 and the 
interrupt controller 68 as well as connect the 
wireless receiver 2 7 to the power supply 3 5 

10 illustrated in FIG. 1. In the embodiment illustrated, 
the interrupt controller 68 is shown as being separate 
from the processor 20. In other embodiments, the 
interrupt controller 68 can be designed as part of the 
processor 20. The components of the wireless receiver 

15 27 can be manufactured using known fabrication 
techniques as implemented in pagers, GSM phones, 
cellular phones or the like. Although illustrated and 
discussed > below with respect to the processor 62, it 
should be understood that discrete components can also 

20 be used in place of the processor 62. 

Operation of the wireless receiver 2 7 and 
the mobile device 10 is directed to efficiently use 
power from the power supply 3 5 in order to maximize 
the operational time between recharging or replacement 

25 of the battery 37. In one preferred embodiment, the 
wireless receiver 27 is powered and capable of 
. receiving information from the wireless transport 14 
at all times irrespective of whether other components 
of the mobile device 10 are operational and receiving 

3 0 power. This allows the wireless transport 14 to send 
information to the mobile device 10 even if the user 
is not interacting with the I/O components 24 of the 
mobile device 10 . 
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When it is desired that the mobile device 10 
receive information at all times, power from the power 
supply 35 is principally provided to the interrupt 
controller 68 and the wireless receiver 27, while all 
5 other components of the mobile device 10 do not 
receive power, or receive only enough power to operate 
in a "suspend" mode or state. For instance, the 
processor 2 0 can have three different .modes of 
operation designed to maximize battery life by 

10 minimizing power consumption; full speed, standby and 
suspend. Full speed mode is used to execute 
applications. Standby mode is used during brief idle 
periods. Standby mode can use less than one-tenth 
(l/10th) of full speed power. Suspend mode is used 

15 during long idle periods. Suspend mode can use J.ess 
than one-one thousandth (1/I000th) of full speed 
power . 

FIG. 6 illustrates a method of operation 80 
of the mobile device 10 and the wireless receiver 27 

20 to process information from the wireless receiver 27. 
At step 82, the wireless receiver 27 and the mobile 
device 10 await information to be sent from the 
wireless transport 14 . It is assumed that only the 
wireless receiver 27 and the interrupt controller 68 

25 are receiving power and operating, . while all other 
components are either off or are in a suspend state, 
as discussed above. 

At step 84, information is received by the 
RF receiver 60 from . the wireless transport 14 . The 

30 information is then processed by the wireless receiver 
27 at step 86. In the embodiment illustrated, the 
processor 62 initially analyzes the information 
received and determines if the information requires 
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further processing by the processor 20 of the mobile 
device 10 and/or storage of the information in the 
object store 18. If at step 86, the processor 62 
determines that the processing or storage components 
5 of the mobile device 10 are not needed, operational 
flow continues to step 88 whereat the wireless 
receiver 27 processes or discards the information 
received. For instance, upon processing, the processor 
62 can determine that the information received does 

10 not pertain to the mobile device 10, such as when a 
wireless address (capcode) does not pertain to the 
mobile device 10, and thus, the information can be 
discarded. Alternatively, the processor 62 can 
determine that all of the information can be 

15 temporarily stored in memoiy 64 for later retrieval by 
the processor 20 of the mobile device 10. After 
processing the information at step 88, operational 
flow returns to step 82 where the wireless receiver 27 
awaits further transmitted information. 

20 Steps 86 and 88 illustrate how the wireless 

receiver 27 can receive and process information 
without further interaction with other components of 
the mobile device 10. Thus, power consumption from the 
power supply 35 is conserved since none of the other 

25 components of the mobile device 10 have been turned on 
or operated at a higher power consumption rate . 

If at step 86, the wireless receiver 27 
determines that the information received must be 
further processed by the mobile device 10, operational 

30 flow continues to step 90. At step 90, the processor 
20 is awoken by the interrupt controller 68 as 
initiated by the processor 62. The processor 20 
retrieves the information stored in memory 64 and 
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processes it to determine if user interaction is 
required. If user interaction is required, operational 
flow proceeds to step 92 whereat user input devices 
such as the keyboard 3 2 are activated and the user is 
5 notified of the information through the display 34. 

If at step 90, the processor 20 determines 
that user interaction is not necessary to process the 
information, the processor 20 processes the 
information, turning on only those components of the 

10 mobile device 10 that are necessary at step 94 . For 
instance, the information received by the wireless 
receiver 2 7 could have exceeded the memory 
capabilities of memory 64 and that the only required 
action is to store the information in the object store 

15 18 or other temporary memory provided in the mobile 
device 10. In such a case, it is not necessary to 
activate or turn on the keyboard 32 or the display 34. 
The processor 2 0 merely performs the required actions 
such as storing the information in memory in the 

20 mobile device 10 and returns to the suspend mode. 
Operational flow then returns to step 82 whereat the 
wireless receiver awaits further transmitted 
information. 

Steps 9 0 and 94 thus illustrate how power 

25 consumption is conserved since only a partial wake-up 
of the mobile device 10 has been performed to process 
the information. In other words, since only those 
components necessary to process the information have 
been turned on, while other components such as the 

3 0 display 34 remain off, power has been conserved and 
battery life has been extended. 

At this point, it should also be noted that 
power can also conserved by monitoring the source of 
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system wake-ups and powering down the system as a 
function of the source. In particular, if the system 
is started in order to process an incoming message 
from the radio receiver . 27, the system can be 
5 immediately shutdown upon the completion of 
processing. In contrast, when the system is started by 
the user using the power button 40, or when the system 
starts to provide the user a scheduled notification, 
such as an upcoming appointment , commonly the . system 

10 will shutdown when a period of non-use has occurred. 
Rather than waiting for the non-use period to lapse 
for processing an incoming message, the system will 
shutdown immediately. However, if the system comes up 
because of the radio receiver 27 and then the user 

15 turns on the system, the system is allowed to remain 
up and shutdown if the non-use period lapses. The 
source of system start can be monitored by the 
interrupt controller. 68 . 

FIG. 7 illustrates a detailed method of 

20 operation of the wireless receiver 27 and the mobile 
device 10. Generally, the wireless receiver 27 and the 
mobile device 10 process three types of incoming 
messages. A first type of message is not related to 
the mobile device 10 and is discarded. A second type 

25 of message is for the mobile device 10, but either can 
be received now for further processing at a later 
time, or can be received and processed at a later 
time. A third type of message is a high priority 
message that must be processed immediately and may 

3 0 require user interaction. All of these messages are 
efficiently handled by the method of FIG. 7 to 
conserve power and maximize battery life. 

In FIG. 7, wireless data 102 is received by 
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the wireless receiver 27, as indicated at step 104. At 
step 106 , the wireless information is examined by the 
processor 62 to ascertain if the wireless address of 
the information pertains to the mobile device 10. 
Typically, the wireless receiver 27 will be configured 
to respond to multiple wireless addresses, wherein 
each wireless address is used by one or a number of 
services to send information to the mobile device 10. 
For instance, one wireless address can be used to send 
high priority or personal messages to the mobile 
device 10, while other wireless addresses are used by 
one or more services to send other information to the 
mobile device 10. At step 106, the processor 62 
ascertains if the wireless information pertains to a 
valid wireless address of the mobile device 10. If the 
wireless information does not pertain to .the mobile 
device 10, it is discarded at step 108. 

At step 110, valid information for the 
mobile device 10 is stored in memory 64 of the 
wireless receiver 27. At this step, the processor 62 
ascertains whether all of the information can be 
stored in memory 64, or if the mobile device 10 must 
be at least partially woke up. If the entire incoming 
information can be stored in memory 64, and the 
information is not high priority, the processor 62 
stores the incoming information at step 112. If, on 
the other hand, the processor 62 determines that the 
incoming information cannot be completely stored in 
memory 64, or that the incoming information pertains 
to a high priority message, for example, based on its 
wireless address, an interrupt request is generated at 
step 114 to wake up the processor 2 0 of the mobile 
device 10. 
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At this point, it should be noted that the 
size of memory 64 is proportional to the rate at which 
wireless information is received by the wireless 
receiver 27 and the amount of time necessary for the 
5 processor 20 of the mobile device 10 to wake up and 
begin extracting information from memory 64. .In one 
embodiment, the minimum amount of memory is provided 
in the wireless receiver 2 7 to store information until 
the processor 20 wakes up. In this manner, the size of 

10 memory 64 present in the wireless receiver 27 is less, 
thereby reducing the overall size of the wireless 
receiver 27 and reducing its cost. 

At step 116, the processor 20 of the mobile 
device 10 executes an initial body ..of code herein 

15 called the -hardware abstraction layer (HAL) . As part 
of the HAL wake -up code, HAL can call a function 
herein identified as CheckAndProcessRadioWakeup ( ) . 
Generally, this function checks if the radio receiver 
27 needs some service and whether this service can be 

20 handled within HAL or if more components of the device 
will need to be started. The return values include: 
(1) a first value indicating that the radio receiver 
27 has been serviced and there is no need to start 
other components (herein the first value is 

25 n HRADIO__NO CONTINUE 11 ) ; (2) a second value indicating 
that the display 34 should be turned on (herein the 
second value is n HRADIO_CONTINUE_VIDEO_ON" ) ; and (3) a 
third value indicating that the display 34 should not 
be turned on (herein the third value is 

30 "HRADIO_CONTINUE_VIDEO_OFF") . It should be noted that 
the return values can be ignored if other wake -up 
events occur. For instance, if the user presses the 
power button 40 about the same time as a radio 
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interrupt is- also received, and if the return value is 
" HRADIO__NOCONTINUE " or "HRADIO_CONTINUEJVTDEO_OFF" the 
return value is ignored. In one embodiment, the radio 
receiver 27 registers information in a data block 
5 accessible by the HAL program indicative of the return 
values. The function is further described in detail in 
the Appendix along with other functions and related 
information. 

Based on the return values, the processor 2 0 

10 retrieves the information stored in memory 64 and 
examines it to determine if the processor can store 
the information temporarily in a temporary buffer 
herein called the HAL buffer 120. If temporary storage 
in the HAL buffer is possible, program flow continues 

15 to step 118 whereat the processor 2 0 executes a device 
driver buffering routine which stores the information 
in the HAL buffer 120 as indicated at step 120. The 
processor 2 0 then returns to the suspend state as 
indicated at step 122. 

2 0 If, on the other hand, at step 116, the 

processor 20 determines- that the information cannot be 
stored in the HAL buffer 120, for instance, where the 
information is high priority or of length exceeding 
the storage available in the HAL buffer 120, the 

25 processor 20 continues its wake-up process and a 
kernel is loaded at step 124. Each of the device 
drivers, such as a display driver, a serial port 
driver, etc., is then loaded at step 126. "One 
. particular driver that is loaded is a pager driver, 

30 which executes a filtering library function is 
indicated at step 12 8. The pager driver examines the 
information at step 130 to determine if the 
information is relevant to the mobile device 10. In 
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contrast to step 106 where information is discarded if 
it • does not correspond to a wireless address 
recognized by the mobile device 10, information is 
discarded at step 13 0 if, based on its content, it is 
5 not relevant to the mobile device 10. For instance, 
the user may want to receive only football scores and 
no other sports scores. However, all of the sports 
scores may be transmitted with respect to a particular 
wireless address, thus information on baseball scores 

10 would not be discarded at step 106 since this 
information was transmitted with respect to the 
correct wireless address for football scores. However, 
at step 130, the content of the information is 
examined so baseball scores would be discarded, while 

15 football scores are retained. Steps 116 to 128 are 
very efficient and quick. In particular, the filtering 
step 128 examines the initial few bytes of the 
information and can quickly determine if the 
information should be kept or discarded. The number 

2 0 and location of the bytes to examine are predetermined 
and agreed upon between the wireless information 
carrier and software developers . By examining only the 
first few bytes, the filtering step 128- can execute 
quickly (the processor 20 is up for less time) and 

25 does not require all of the operating system services 
to be started. Non-relevant information is discarded 
at step 132. It should be noted that upon loading of 
the pager driver at step 128, any information stored 
in the HAL buffer 120 at step 120 from prior messages 

30 is retrieved and processed. 

It should be noted that in a further 
embodiment, the filtering step 128 can include other 
filtering parameters settable by applications 
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executable on the mobile device 10. In other words, 
besides filtering on designated bytes within the 
message, as discussed above, the filtering library 
function can include other filtering parameters 
5 determined by application programs. For instance, a 
news viewer application can set a filter parameter 
where the mobile device 10 always rejects and does not 
store digital pictures and accepts only the 
accompanying text. The filter. parameters can be passed 

10 from the application to the filtering library at 
filtering step 128 using, for example, application 
program interfaces (APIs) . Filtering based on content 
is described in detail in co-pending application 
entitled "LOW LEVEL CONTENT FILTERING" , filed on even 

15 date herewith and incorporated herein by reference. 

If the information is relevant to the mobile 
device 10 and should not be discarded, program flow 
continues. to step 134 to determine if user interaction 
is needed. For instance, if the message pertains to a 

2 0 high priority message requiring acknowledgement by the 
user, the mobile device 10 completely wakes up with 
activation of the display 34 to indicate that a 
message of high priority has been received. A full 
wake-up is indicated at step 136. 

25 In one embodiment, high priority messages 

are ascertained as a function of wireless addresses. 
FIG. 8 is a pictorial representation -of a list of 
wireless addresses 160. Associated with the radio 
addresses is information as to which addresses are 

30 "high priority" . In the embodiment illustrated, 
priority status entries 161 are provided and are 
settable when an address is for high priority. Any 
information or message that arrives on an address 
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whose priority status entry 161 has been set will 
cause a full wake-up of the mobile device 10. 

If the information does not require user 
interaction, program flow continues to step 138/ At 
5 step 138, if buffer space exists and no further 
processing is necessary, the processor 20 executes a 
buffer data routine at . step 140 to store the 
information at step 142. The processor 20 then returns 
to the suspend state at step 122. If buffer space does 

10 not exist at step 138, the mobile device 10 is 
powered-up without the display 34 at step 144 . The 
information is then processed or additional buffer 
space is obtained at step. 146. If necessary, access 
and storage can be made in the object store 18. The 

15 processor 20 then returns to the suspend state at step 
122. It should be noted that considerable power has 
been conserved since the user input/output (I/O) 
devices (display 34 and keyboard 32) have not been 
powered. However, if the user were to activate the 

2 0 mobile device 10 to turn it on, the display 34 would 
immediately enable. 

The mobile device 10 processes incoming 
wireless messages according to the above-described 
method in the background whether or not the user is 

2 5 actively interacting with the mobile device 10 using 

the I/O components 24. It should be noted that if the 
user were to turn off the mobile device 10, the 
wireless . receiver 27 will remain powered to receive 
incoming messages. If the user were to turn off the 

3 0 power during processing of an incoming message, the 

display 34 would turn off to indicate at least partial 
shut down of the mobile device 10; however, the 
incoming message would be processed according to the 
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above -described procedure. In this manner, the "power 
off n signal is trapped and processed when processing 
of the incoming message is complete (unless the 
processing of the message results in the need to 
5 perform a full wake -up) . 

Another aspect of the present invention 
allows for selective enabling and disabling of 
wireless addresses recognized by the wireless receiver 
27. Referring back to step 106 in FIG. 7, the 

10 processor 62 (FIG. 5) examines the wireless address of 
information received and discards information at step 
108 that does not pertain to a wireless address 
associated with the mobile device 10. One aspect of 
the present invention includes maintaining a list of 

15 recognized wireless addresses/ for example, in memory 
64, that the processor 62 can access when information 
is received. As stated above, FIG, 8 is a pictorial 
representation of a list 160 of wireless addresses. 
Each wireless address in the list 160 includes an 

2 0 associated operational status entry 163 indicating 
whether the wireless address is enabled or disabled. 
In a preferred embodiment, the list of wireless 
addresses is static in that the wireless addresses can 
not be changed by the user. However, whether the 

25 wireless address is enabled or disabled is under the 
control of the user and/or programming provided in the 
mobile device 10. Referring back to FIG. 5, the 
processor 2 0 of the mobile device 10 can selectively 
enable or disable each wireless address in the list 

30 160 in memory 64 via the bus 28 and the interface 
controller 66. 

Selective enabling and disabling of wireless 
addresses allows the mobile device 10 to further 
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extend battery life by not receiving inf ormation that 
is not of high priority. For instance, the user may 
subscribe to an information service that provides 
general sports information that is transmitted with 
respect to a certain wireless address . This 
information -may be repeatedly transmitted over a given 
time period such as a number of hours. If the wireless 
receiver 27 were to continually process the 
information each time it is transmitted, possibly 
waking up the mobile device 10 to process the 
information, . the battery 37 (FIG. 1) can be quickly 
depleted. By selectively enabling or disabling the 
wireless address in the list 160 pertaining to this 
information, the wiireless receiver 27 can quickly 
discard the information at step 106 (FIG. 7) in order 
tc conserve battery power. For instance, the processor 
20 of the mobile device 10 can enable the wireless 
address pertaining to sports information .in list 160 
when the mobile device 10 is receiving power from the 
external power source 41 (FIG. 1) . If the mobile 
device 10 is operating under battery power, the 
processor 20 can disable the wireless address 
pertaining to the sports information in order to 
extend battery life. 

Although the present invention has been 
described with reference to preferred embodiments, 
workers skilled in the art will recognize that changes 
may be made in form and detail without departing from 
the spirit and scope of the invention. 
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APPENDIX 

1.1.1 Overview 

Wireless Services for Windows CE defines a hardware, device drivers, and overall 
architecture for the incorporation of message-based radio into a Windows CE 
device. The goal is to create a framework within which applications, system 
services and hardware all remain modular with respect to each other, thus 
providing the environment for a wide range of applications. 

This appendix addresses what support the device drivers need to provide to meet 
the following requirements: 

1 . Power saving achieved by not waking up the whole system. 

2. Doing background processing without turning on video 



1.1.2 Terminology 



Device 


Windows CE hardware (e.g. Palm PC, Auto PC) 


Radio 


Radio HW for a device (e.g. a paging card) 


OEM 


Original Equipment Manufacturer - In this document this term refers to the 
device manufacturers 


IHV 


Independent H W Vendor — In this document IHV refers to the radio 
manufacturer (who develops the HW and/or device driver) 


HAL 


Hardware Abstraction Layer. This is implemented by each OEM to abstract their 
HW implementations from the Windows CE operating system. 


LCD and VIDEO 


These two terms have been used interchangeably and refer to the display panel 
on the device. 
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1 .1 .3 Overview ?' 

A typical radio device listens to the .radio 
transmissions and determines if there is a message for 
the user. This determination is based on one or more 
"addresses' that are programmed in the radio receiver 
or hardware (HW) . The radio HW is powered 
independently (i.e., it is powered even when the 
Windows CE device is powered down) and. the radio HW 
carries out the lowest level of filtering without 
requiring the Windows CE device to be powered on. This 
achieves some level of power savings since radio HW- 
typically require only a fraction of power compared to 
the Windows CE device. 

Wireless Information Services for Windows CE provides 
for additional levels of filtering that may or may not 
be carried out in the radio HW. If the radio HW is 
separately powered and has enough logic to do 
additional filtering independent of the device CPU, 
then it will not cause major power drain from the 
device power supply. However, it is expected that the 
majority of the radio HW will be in the Compact Flash 
card type II form factor (a form factor for most 
devices) and will not have separate power or CPU due 
to size constraints. These cards, therefore , . will 
cause a wakeup of the device so that some processing 
is carried out in the device driver. 

Another way to achieve power saving is not to wakeup 
the system for each message but to buffer them for 
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group processing at a later time. The radio HW may not 
have enough memory and to use the Windows CE device 
memory for this purpose will ordinarily require the 
device to be woken up to run the device driver code 
that copies message from the radio HW to the system 
memory. In this case we want the system to be up for a 
very short duration and there is no need for the 
display and other subsystems to be powered on. 
Thus, the power saving goals can be summarized as: 

• System comes up quickly and stays powered on for as little time as possible 

• The LCD is not turned on until it is needed 

• System shuts down as soon as possible (currently, once the system is up, it does a 
time out of the order of 1-5 minutes to shutdown) 

To achieve the above goals, Win CE Radio device drivers support a state called Partial 
Wakeup state. This refers to the device state just after wakeup where HAL has initialized 
but the kernel and file system are not fully initialized. The objective is to do some 
processing in this state to filter out unwanted messages and shut down the system as soon as 
possible, ideally from the partial wakeup state itself. 

1 .1 .4 Driver Support for Partial Wakeup 

This section describes what support needs to be provided in the driver. 

1.1.4.1 RIO JnttQ 

During system initialization, radio driver initialization function RIO_Init() is called. 
In addition to the other initialization, it should call a MS supplied function called 
RegisterWakeupQ and supply the address of a call back function as parameter. The 
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call back function (called CheckAndProcessRadioWakeupO in this document) is 
described below. 



See section 1.1.8 for sample code for RIO_init() function. 

Section 1.1.6.1 describes RegisterWakeupO function that does the following: 

1. Calls VirtualAllocO to allocate needed memory space. This space will 
be used to store pointers to buffers for radio and other data (e.g. data 
for filtering functions). This memory is referred to as Radio Control 
Block. 

2. Makes the kernel call to lock the driver code and allocated buffers in 
memory. 

3. Calls HAL IOCTL calls and registers a function in driver space that 
will be called by HAL during warm boot when the wakeup source is 
radio (this function, called CheckAndProcessRadioWakeupO in this 
document, determines if the wakeup should continue or not). HAL 
maintains a data structure for each device driver to store this function 
pointer. 



1.1.4.2 Registered wakeup callback function 

The radio driver is expected to supply a function which will be called during the 
system wakeup sequence from HAL. This function executes in the partial wakeup 
state and therefore has many limitations and requirements (described later). The 
main purpose of this function is to achieve power savings for the device. Power 
saving is achieved in many ways as listed below: 

• The function could simply read the data off the radio HW and buffer it in the 
memory blocks for later processing. It could also implement low level filtering 
(e.g. group level filtering, if the radio HW is not capable of doing it). In this 
case the function returns a value indicating that system wakeup is not required 
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(in this scenario this function acts like an interrupt service routine, quickly 
servicing the radio HW and shutting down the system as soon as possible) 

• If the system buffers are full, the function could return a value indicating to the 
HAL that a system wakeup is required but there is no need to power the 
display- In this scenario, the system will wakeup and execute message router 
and other components that process the messages and most likely will shut 
down the system after processing is complete. 

• If the data is high priority (e.g. a personal page), the function should return a 
value indicating to the HAL that a full system wakeup is required because this 
message will most likely cause a user notification. 

1 ;1 . 5 Data Structures *.>. ; ? 
1.1.5.1 Radio control block 

The radio control block data structure is maintained by HAL. A pointer to the radio 
control block is passed to the registered function (called 
CheckAndProcessRadioWakeupO in this document). The radio control block 
holds pointers to memory blocks that contain data or code. These memory blocks 
are allocated using VirtualAlloc() function, are locked down so that they are 
accessible during partial wakeup state, and are accessed using physical addresses. 

The radio control block is an array of RADIO_BLOCK which is defined below: 
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typedef struct _hradio_block { 



DWORD dwld; 

DWORD PAddr; 
block 

DWORD VAddr; 
block 

DWORD dwSize; 



// Block ID 

// Physical address of 

// Virtual address of 

// Size of block 



) H RADIO BLOCK, *LPHRADIO_BLOCK; 



The block can be either a pointer to code or a pointer to data as determined by the 
dwld field. The Ids are generated using macros defined in the next section. 

1.1.5.2 Block ID Macros 

The radio control block stores pointers to code or data that needs to be accessed 
during partial wakeup state. The entries are tagged using an id, which is generated 
using one of the macros defined below: 



HRADIO_MAKE_DRIVER_ID (Par 1 , Par2) 

Generates an id for a driver function or data block. Pari can be either 
HRA D 1 0_D AT A (for defining a data block pointer) or HRADIO_CODE 
(for defining a function pointer). Par2 is an unsigned 16-bit value. 



HRADIO_MAKE_SYSTEM_ID (Pari, Par2, Par3) . 

Generates an id for a known system function or data block. These ids are 
used internally by the system and should not be used by the device drivers. 
Pari can be either HRAD10_DATA (for defining a data block pointer) or 
HRADIO_CODE (for defining a function pointer). Par2 and Par3 have 
the following meanings: 
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Par2 


Par3 




0 


HRAD I O^WAKEUP 


Pointer to the partial 
wakeup call back function 
or data 


0 


HRAD I 0_ANALYZE_MSG 


Pointer to the 
AnalyzeMessage ( ) function 
or data 


0 


HRAD I 0_F I LTER 


Pointer to the 
FilterMessage ( ) function or 
data 


Address 


Group 


Pointer to application 
filter function or data for 
. the given address /group 
combination 



1.1.6 Function Reference - MS Supplied Functions 
1.1.6.1 RegisterWakeup() 

This function does the following: 

Creates the Radio control block (VirtualAlloc(), lock it, register with the HAL) 

Makes HAL IOCTL call to register the wakeup callback function (which will 
be called by HAL during partial wakeup sequence) 

Makes HAL IOCTL call to register AnalyzeMessage() function (which 
deciphers the message header) 

Makes HAL IOCTL call to register FilterMessageO function (which invokes 
the application level filtering functions) 

Syntax 
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LPHRADIO_BLOCK RegisterWakeup( 
BYTE Deviceld, 
BYTE NumBlocks, 
LPVOID pWakeupFn, 
DWORD dwWakeupFnSize) 

Parameters 

Deviceld Identifies the device controlled by this driver (this 

parameter is derived from the parameter passed 
to the RIO_Init() function) 

NumBlocks Number of additional radio control block entries needed 

by the driver (driver will need one entry for each 
buffer or function it intends to use during partial 
wakeup state). This does not include system 
required entries, e.g. the partial wakeup callback 
function etc. 

pWakeupFn Pointer to the partial wakeup callback function. 

dwWakeupFnSize Size in bytes of the partial wakeup callback 

function. If not used, pass a 0 value. 

Return Value 

Returns pointer to the radio control block if successful, NULL otherwise. 

1 .1 .6.2 LocateAndCal!AnalyzeMessage() 

This function locates and invokes the AnalyzeMessageO function in partial 
wakeup state (driver can call the AnalyzeMessageO function directly in other 
places). 
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Syntax 



BOOL LocateAndCallAnalyzeMessage ( 



VOID *pMsg, 



DWORD dwMsgLen, 



BOOL *pfDiscard, 



BYTE * pGroupCode) 



Parameters 



pMsg Pointer to the message bytes. 



dwMsgLen 



Length of the message. 



pfDiscard 



Receives a BOOL value indicating whether the message 
should be discarded or kept. 



pGroupCode Receives the Group code. 
Return Value 

Returns TRUE if message had a valid WS header, FALSE otherwise. When it 
returns TRUE, pGroupCode receives the group code and pfDiscard receives a 
BOOL value indicating whether the message should be kept or not 
(TRUE=discard). 



This function locates and invokes the application level filtering mechanism . 
Syntax 

BOOL LocateAndCallFilterMessage ( 
VOID *pMsg, 
DWORD dwMsgLen, 



1 .1 .6.3 LocateAndCallFilterMessage() 
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BYTE Address, 
BYTE GroupCode) 

Parameters 

pMsg Pointer to the message bytes. 
dwMsgLen Length of the message. 
Address Address number this message came on. 
GroupCode Group code this message came on. 

Return Value 

Returns TRUE if message should be kept, FALSE if it should be discarded. 

1 .1 .6.4 RegisterBlock() 

Allocates a memory block, locks it down, and creates an entry in the radio control 
block for it. Then data from the supplied buffer is copied into this newly allocated 
memory block. 

Syntax 

LPHRADIO_BLOCK RegisterBlock (BYTE Deviceld-, 
DWORD dwBlockld, 

LPBYTE IpbData, 
DWORD dwDataLen) 

Parameters 

Deviceld The block will be added to the radio control block for this 

device. 
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dwBlockld 



Block Id to be assigned (This id must be output of macros 



defined in 1.1.5.2) 

IpbData Pointer to the data that will be copied in a newiy allocated 
memory block. 

dwDataLen Length of the data (this is the size of the newly allocated 
memory block) 

Return Value 

Null is returned if data block can't be created, pointer to the created radio block is 
returned otherwise. 

Remarks 

The dwBiockld also indicates whether the block is a code block (function) or data 
block (buffer). 



This function searches the radio control block for the given block id. 
Syntax 

LPHRADIOJ3LOCK LocateBIock (BYTE Deviceld, DWORD 
dwBiockld) 

Parameters 

Deviceld The block will be searched in the radio control block for 



1.1.6.5 LocateBlockQ 



this device. 



dwBiockld 



Block Id to be assigned (This id must be output of macros 
defined in 1.1.5.2) 
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ReturnValue 

Returns pointer to radio block if ID found, else returns NULL 

1.1.6.6 Busy() 

This function increments or decrements the system busy counter. 
Syntax 

WORD Busy(BYTE State) 
Parameters 

State If TRUE, increments the busy counter. FALSE decrements busy 
counter. 

ReturnValue 

Returns current value of system busy counter. 

1.1.6.7Video() 

This function turns the video on or off. 
Syntax 

BOOL Video(BYTE State) 
Parameters 

State If TRUE, turns video on. FALSE turns video off. 
ReturnValue 

Returns TRUE if operation completed, FALSE otherwise. 
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I.I J Function Reference- IHV Supplied Functions 

1.1.7.1 CheckAndProcessRadioWakeup() 

This function is statically part of the radio driver but is called by the HAL during 
warm boot. The main purpose of this function is to check if the radio device needs 
some service and whether this service can be handled within HAL or it requires the 
whole system to be woken up. 

Syntax 

DWORD CheckAndProcessRadioWakeup ( 

DWORD MemPtr Pointer to radio control block 

) ' 

Description 

This function is called in response to the wakeup interrupt from the radio device 
(RING_INDICATE interrupt). This function is called by HAL before the kernel is 
initialized {partial wakeup state). Because of this, this function must meet the 
following criteria: 

• The function must be on a page boundary. 

• The function will be executed in physical mode 

• The function must not call any OS or file system calls. 

• The function must not call any other function. (If it needs to call other 
driver supplied functions, they must be called via a function pointer 
table initialized during startup. See Error! Reference source not 
found, and Error! Reference source not found, for details.) 
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The function should read the data from the radio device and determine if the data 
needs to be kept or discarded. If the data needs to be kept, it should further 
determine if it is high priority data (see device driver specifications for discussion 
of address and group property flags). High priority data needs to be processed 
immediately and will require a full wakeup. Low priority data may be buffered in 
memory allocated during startup. If that memory is full, a full wake up is again 
required to flush that memory. In either case, the data is read off the radio device 
and appropriate return value is passed to the HAL. 

The skeleton of this function is: 

read data off the radio HW 

Call AnalyzeMessageO to get the group code information from the 
message header 

Do group level filtering (if the HW has not done it) 

Invoke application level filtering mechanism. Do message filtering 
based on the return code. 

if message is to be kept, then buffer it and return appropriate return 
code 

Since this function is executed during the partial wakeup state, it can not make 
function calls directly. Instead a support library has the following two functions to 
invoke the AnalyzeMessageO and filter mechanism: 

LocateAndCallAnalyzeMessageO - this function invokes the 
AnalyzeMessageO function described in the device driver specifications. 

LocateAndCallFilterMessageO — this function invokes application level 
filtering (to be documented). 

Return Values: 
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HRADIOJNTOCONTINUE 

The device has been serviced, no need to continue the warm boot. An 
example of this case would be when the radio device has a new message 
that can be buffered in the system memory (done by this function) and no 
further processing is required. 

HRADIO_CONTINUE_VIDEO_ON 

The device service needs the system to continue the warm boot with video 
(the video should be powered on too). An example of this case would be 
when a message is received on a priority address that will cause a 
notification to be issued. 

HRADIO_CONTINUE_VIDEO_OFF 

The device service needs the system to continue the warm boot without 
video (the video should not be powered on). An example of this case 
would be when a broadcast message is received when the system memory 
buffer is full, so processing should continue without video so the system 
buffer can be flushed. 

) 

Remarks: 

The partial call back function is quite similar to the interrupt service function (ISR) 
(also supplied by the driver). However, there are some significant differences as 
outlined below: 



ISR 


Partial wakeup caii back function 


Registered using CardRequestlRQQ 


Registered using RegisterWakeupO 


Registered for a specified socket and function 
pair. 


Registered for a driver. 


Interrupt condition cleared by Card Services. 


Call back function needs to clear the interrupt 
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condition. 


Return as quickly as possible. If more processing 
needed, spawn a thread and return. 


Return as quickly as possible, can not spawn a 
thread. 


Kernel and file system services available. 


No kernel or file system services. 


Always called to handle the interrupt from the 
radio HW. 


Called only if the interrupt causes a system 
wakeup (if the system is already up at the time of 
the interrupt, only the ISR gets to execute). 


Responsible to copy the message from the radio 
HW, to analyze it, and to filter it. Can call the MS 
supplied functions directly to do these. 


Responsible to copy the message from the radio 
HW, to analyze it, and to filter it. Can call the MS 
supplied functions using special indirection 
methods only. 


Is a normal user-mode function. 


Is a special function that executes in physical 
mode and has special restriction on it (e.g., must 
be on a page boundary, can not call other 
functions, etc.) 



1.1.8 Sample Code 
1.1.8.1 RIO_lnit() 

HINSTANCE HalLib; 
LPHRAD IO_BLOCK HalMem; 

// Since the Register function needs to be located on 
//a page boundary, the following pragma assures that. 
DWORD CheckAndProcessRadioWakeup (DWORD) ; 

#pragma alloc_text {". wakeup", CheckAndProcessRadioWakeup) 
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HalLib = LoadDriver (TEXT £ "riohal . dll" ) ) ; 
if (HalLib) { 

func = GetProcAddress (pRadioCtl->HalLib, 
TEXT ("RegisterWakeup") ) ; 

if (func) { 

// Call RegisterWakeup () 
HalMem = (LPHRADIO_BLOCK) 

(*func) ( (DWORD) CheckAndProcessRadioWakeup) ; 

) 

} 
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1 .1 .8.2 CheckAndProcessRadloWakeup() 

LPBYTE pAddressTag, pGroupTag; 

BOOL f Discard, f Group Found; 

BYTE GroupCode; 

char *p, buf[1000]; 

BYTE bMsgBuf [MAX_MSG_SIZE] ; 

WORD dwMsgSize; 

char address » 1; 

// Fill szMsgBuf [] with message data from the Radio HW 
// do group filterning 

fGroupFound = LocateAndCallAnalyzeMessage (bMsgBuf , dwMsgSize, 

&f Discard, &GroupCode) ; 

if (fGroupFound) { 

if (fDiscard) { 

// discard message 
return HRADIO_NOCONTINUE; 

} 

// Search driver data structure for group info relating 
to 

// the address this message came on and the group code 
// (returned by the AnalyzeMessage ( ) above 
// if GroupCode is not found or it is disabled then 
// also discard the message 

if (! LocateAndCallFilterMessage (bMsgBuf , dwMsgSize, 

Address, GroupCode)) 

( 

// discard message 
return HRADIO NOCONTINUE; 
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} 

// here buffer the message and return HRADIO_NOCONTINUER 
// if buffer full then return HRADIO_CONTINUE_VIDEO__OFF 
} else { • 

// treat as a normal page message (cause full wakeup, 
etc.) 



return HRADIO_CONTINUE_VIDEO_OFF; 

} 



1.1.9 Type Definitions 

This section defines the types used in the driver API. 

1.1.9.1 Basic Types 

The following basic types are used: 
BYTE Unsigned 8 -bit 
WORD Signed 16 -bit 
DWORD Signed 3 2 -bit 

1 .1 .9.2 Complex Types (structs) 

All structures have the following three fields at the beginning: 

WORD wOperationCode Indicates what operations needs to be performed. This 

field also determines the rest of the struct. 

WORD wStructSize Each struct has fixed size fields followed by the length of 

the variable fields. The variable fields follow in 
the same order as their lengths. The wStructSize 
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field holds the size in bytes of the fixed pan of 
the struct (i.e., fixed fields and the lengths of the 
variable fields). This field provides a versioning 
method as well and will be used for backward 
compatibility in the future releases. 

In addition, the variable length fields are grouped towards the end a length field for 
each one of them is provided. This allows expanding these structures without 
losing backward or forward compatibility. 

1.1.9.3 struct HRADIO_REGISTER 

This struct is used for registering a wakeup function. 



Size 


Field 


2 


WOperationCode 


2 


WStructSize 


4 


DwMemPtr 


1 


Device 



WORD wOperationCode 

HAL_I OCTL_CMD_REG I STER^W 
AKEUP_FUNCT ION 
WORD WStructSize sizeof (HRADIO_REGISTER) 

DWORD dwMemPtr Pointer to a memory block (RMB) . 

The second DWORD of this 
memory block contains a 
pointer to the function that 
will be called by HAL during 
wakeup to determine if power 
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on sequence should continue 
or not . 

BYTE Device Device number (This is how HAL 

distinguishes one device's 
RMB from another) . 



1 .1 .9.4 struct HRADIO_FLAG 

This struct use used for operations on the HAL flags. 



Size 


Field 


2 


WoperationCode 


2 


WStructSize 


2 


wFlag 



WORD wOperationCode One for the following values : 

HRADIO_CMD_FLAG_SET 
HRAD 1 0_CMD_FIAG_CLEAR 
HRAD 1 0_CMD__F!LAG_GET 
WORD WStructSize sizeof (HRADIO__FLAG) 
WORD wFlag A code indicating which HAL flags 

is affected by the requested 
operation. Values are: 

HRADIO_FLAG_VIDEO_STATE 

HRADIO FLAG SYSTEM BUSY 
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1.1.9.5 struct HRADIO_LOCK 

This struct use used for operations on locking and unlocking memory. 



Size 


Field 


2 


wOperat ionCode 


2 


wStructSize 


4 


dwMemPtr 


4 


dwSize 



WORD wOperationCode One for the following values: 

HRAD 1 0_CMD_LOCKPAGE 
HRADI 0_CMD_UNLOCKPAGE . 
WORD wStructSize sizeof (HRADIO__LOCK) 
DWORD dwMemPtr A virtual pointer to memory to be 

locked or unlocked. 
DWORD dwSize The total number of bytes to be 

locked or unlocked. 

1.1. 10 HAL Flags 

The following flags form part of the HAL: 



Flag 


Type 


Meaning 


HAL_fVideoState 


Bool 


Set if the video is currently powered on, reset otherwise. 
Set on cold boot. (When the flag is set using 
HRADIO_CMD_FLAG_SET command, the video is 
turned ON. When it is reset, the video is turned off). 


HAL_SystemBusy 


Counter 


This needs to be implemented as a 
counter (at least one byte) . If 
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Flag 


Type 


Meaning 






non-zero, HAL will trap power off 
button to prevent system from 
shutting down. HRAD I 0_CMD_FLAG SET 
command increments the counter, 
HRADIO_FLAG_CLEAR decrements it. 
Initialized to 0 on cold boot. 



1.1.11 HAL IOCTL calls 

In Windows CE systems, HAL supports 10 Control calls to perform operations that 
are specific to their hardware. Most OEMs already implement the following 
IOCTL call for other services. 

Syntax 

BOOL OEMIOControl { 

DWORD dwCode 
PBYTE pBufln 
DWORD dwLen In 
PBYTE pBufOut 
DWORD dwLenOut 
PDWORD pdwActualOut 

) ; 

Parameters 

dwCode Specifies a value indicating the I/O control operation to perform. 

The code used will be IOCTL_HAL_RADIO_CNTRL. 

pBufln Points to the buffer containing data that is input to the HAL. 

dwLenln Specifies the number of bytes of data in the buffer specified for 

pBufln. 
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pBufOut Points to the buffer used to transfer the output data. 

dwLenOut Specifies the maximum number of bytes in the buffer specified by 

pBufOut 

pdwActualOut Points to DWORD buffer the function uses to return the actual 

number of bytes received from the device. 

Return Value 

Returns TRUE if the HAL successfully completed its specified I/O control 
operation, otherwise it returns FALSE. 

1 .1.1 1 .1 HRADIO_CMD_REGISTER 

Syntax 

HRADIO_REGISTER CmdBuf ; 

HANDLE hRegister; 

CmdBuf . wStructSize = 

sizeof (HRADIO_jREGISTER) ; 

CmdBuf . dwOper at ionCode = 
hradio_cmd_register; 

CmdBuf .MemPtr = ...; (NULL for deregis tering) 

CmdBuf . Device = 

BOOL OemlOControl ( 

DWORD dwCode = IOCTL_HAL_RADIO_CNTRL 

PBYTE pBufln = & CmdBuf 

DWORD dwLenln = sizeof (CmdBuf ) 

PBYTE pBufOut = &hRegister 

DWORD dwLenOut = sizeof (HANDLE) 

PDWORD pdwActualOut = &dwWri teBytes 

) ; 

Operation 

-This call registers a radio memory block (RMB) that 
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contains a pointer to the wakeup function that is 
called during HAL power on processing. If the MemPtr 
member is NULL then the call does de-registration. 

The output buffer returns a handle to the RMB (address 
of the HAL -data structure where the device memory 
block was saved) . 

Remarks 

The function supplied must be statically bound to the driver code and 
small enough to fit within a memory page. 

1.1.11.2 HRADIO_CMD_FLAG_xxx 

Syntax 

HRADICMETAG CmdBuf; 
CmdBuf .wStructSize = 8; 

CmdBuf . wOperationCode = HRADIO_CMD_FLAG_xxx; 
CmdBuf. wFlag = ... 

BOOL OemlOControl ( 

DWORD dwCode = IOCTL_HAL_RADIO_CNTRL 

PBYTE pBufln = &CmdBuf 

DWORD dwLenln = sizeof (CmdBuf ) 

PBYTE pBufOut = SdwOldFlagValues 

DWORD dwLenOut = 

sizeof (dwOldFlagValues) 

PDWORD pdwActualOut = SdwWriteBytes 

) ; 

Note: pBufOut, dwLenOut, and pdwActualOut are used for 
GET operation only. Set them, to NULL for other 



DOC ID: <WO 9935557A2_I_> 



SUBSTITUTE SHEET (RULE 26) 



WO 99/35557 



PCT/US99/G0306 



-51- 

operations . 

Operation 

The operation depends upon the operation code stored in 
dwOperationCode member and is described below: 

HAL_IOCTL_CMD_SET_FLAG 

If the indicated flag is a Boolean flag 
then set it to TRUE. If it is a counter 
flag, then increment it. 



HALJOCTL_CMD_RESET_FLAG 

If the indicated flag is a Boolean flag 
then set it to FALSE. If it is a 
counter flag and is non-zero, then 
decrement it . 

HAL_IOCTL_CMD_GET_FLAG 

Value of the indicated flag is returned 
in pBuf Out . For simplicity, the flag 
value is always returned as a DWORD (so 
pBufOut must be large enough to hold at 
least one DWORD) . 

Additional processing for HRADIO_FLA G_ VIDEOJSTA TE: 

If the flag changes its state because 
of a set or a reset command, the video 
needs to be turned on or off to 
correctly reflect the new state of this 
flag. For example, if the 
HAL_fVideoState is 0 and a 
HAL_IOCTL_CMD_FLAG_SET is issued on 
this flag, then the video needs to be 
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turned on. If the flag was already set 
to 1 (hence the video is already on) , 
then this set' command will have no 
effect and there is no need for any 
additional processing (the video is 
already ON) . 

Remarks 

The HAL flags are accessible to the drivers directly (they don't need to 
make these IOCTL calls). 



1.1.11.3 HRADIO_CMD_LOCKPAGE 

Syntax 

HRADIO_LOCK CmdBuf; 
CmdBuf . wStructSize =12; 

CmdBuf . wOperationCode = HRADIO_CMD_LOCKPAGE; 
CmdBuf . dwMemPtr = &buf; 
CmdBuf. dwSize = sizeof (buf ) ; 

BOOL OemlOControl ( 

DWORD dwCode = IOCTL_HAL_RADIO_CNTRL 
PBYTE pBufln = &CmdBuf 
DWORD dwLenln - sizeof (CmdBuf ) 
PBYTE pBufOut = PHYSICAL ADDRESS OF 
LOCKED PAGE 

DWORD dwLenOut = sizeof ( DWORD) ; 
PDWORD pdwActualOut = &dwWriteBytes 

) ; 

Operation 
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This operation locks down the memory pointed to my dwMemPtr. The 
number of pages locked will be determined by the page size and the value 
of dwSize. The value returned will be the physical address of the first byte 
pointed to dwMemPtr. This value will normally be adjusted to be not 
cached and accessible at initial power on. 

1.1.11.4 HRADIO_CMD_UNLOCKPAGE 

Syntax 

HRADIO_LOCK CmdBuf; 
CmdBuf .wStructSize = 12; 
CmdBuf .wOperationCode = 

HRADIO_CMD_UNLOCKPAGE ; 
CmdBuf . dwMemPtr = previous value returned. . 

from HRADIO_CMD_LOCKPAGE; 
CmdBuf . dwSize = previous value used with 

HRADIO_CMD_LOCKPAGE ; 

BOOL OemlOControl ( 

DWORD dwCode = IOCTL_HAL_RADIO_CNTRL 
PBTTE pBufln = & CmdBuf 
DWORD dwLenln = sizeof ( CmdBuf ) 
PBYTE pBufOut = NULL (not used) 
DWORD dwLenOut = 0 (not used) 
PDWORD pdwActualOut = &dwWr i teBy tes 

) ; 

Operation 

This operation unlocks the memory pointed to my dwMemPtr. The 
number of pages unlocked will be determined by the page size and the 
value of dwSize. This function is used to unlock previously locked 
memory. 
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1.1.121 HAL^GD Changes 

The LCD initialization code needs to check the wakeup source and determine if the 
LCD should be turned on or not. If HAL_fVideoRequest flag is implemented, then 
the processing would be as follows: 

if (HAL_fVideoRequest) { 

Continue normal Initialization sequence (the 
LCD is turned on) . 

} else { 

Continue initialization sequence wifcizont 
actually powering on the LCD. 

> 

The LCD code also needs to correctly set HAL_fVideoState flag: TRUE when the 
LCD is powered ON, and FALSE when it is not 

1.1.13 HAL Touch Screen Considerations 

If the touch screen can not be turned of when the video is turned off, then the touch 
interrupt should be ignored if the video is currently off (ie, HAL_fVideoState = 
FALSE). For devices that support the touch screen to turn on the device, then the" 
video should be turned on, and the touch interrupt event should be discarded. This 
can be done by the following code: 

if (HAL_fVideoState == FALSE) { 
HRADIO_FLAG CmdBuf; 

CmdBuf , wStructSize = 

sizeof (HRADIO_FLAG) ; 
CmdBuf - wOperationCode 

=HRADIO CMD FLAG SET; 
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CmdBuf . wFlag = HRADIO_FLAG VIDEO STATE; 



OemlOControl ( IOCTL_HAL_RADIO_CNTRL, 



&CmdBuf , sizeof (CmdBuf ) 
NULL, 0 

pdwActualOut = 
&dwWriteBytes 
) ; 



} 

Note that above is just an example code that uses an HAL IOCTL to turn on the 
video. It is possible that the code to turn on video is trivial (or is available as 
function) in which case that code can be used directly. No matter how this is done, 
care must be taken to ensure that HALJVideoState correctly reflects the true state 
of the video (ON= 1 or OFF=0). 



1. When the HAL detects a key, it also needs to 
check HAL_fVideoState and if it is not set 
(i.e., video is currently not on) then it 
needs to turn on the video using the HAL IOCTL 
call (same code as in touch driver) and eats 
the key. 

2. An additional change is required to implement the delayed power off feature. 
On every power off key press, do the following 

if (HAL_SystemBusy && 



1.1 14 



HAL Keyboard Considfratipns 




{KeyPressed == KEY_POWER_OFF) ) { 



Turn video off and ignore the key 



//see 1.1.13 for the sample code and 



//comment about HAL fVideoState 
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1.1.15 00M system Considerations 



The OOM (out of memory message) code needs to check HAL_fVideoState and if 
it is not set (i.e., video is currently not on) then it needs to turn on the video using 
the HAL IOCTL call. It also needs to clear the HAL_SystemBusy flag. 

Sample Code: 

HRADIO_FLAG CmdBuf; 

CmdBuf . wStructSize = sizoef (HRADIO_FLAG) ; 
CmdBuf . wOperationCode = HRADIO_CMD_FLAG_SET; 
CmdBuf .wFlag = HRADIO_FLAG_VIDEO_STATE; 



OemlOControl ( 

I OCTL_HAL_RAD 1 0_CNTRL , 

& CmdBuf, 

sizeof (CmdBuf) , 

NULL, 

0, 



&dwWriteBytes 



// DWORD dwCode 

// PBYTE pBufln 

// DWORD dwLenln 

// PBYTE pBufOut 

// DWORD dwLenOut 

// PDWORD pdwActualOut 



) ; 



CmdBuf. wFlag = HRADIO_FLAG_SYSTEM_BUSY; 
DWORD dwValue; 



while (1) { 

// get the value of SystemBusy counter 
CmdBuf .wOperationCode = HRADIO_CMD_GET ; 
if (OemlOControl ( 
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I OCTL_HAL_RADI 0_CNT RL , 

& CmdBuf, 

sizeof (CmdBuf ) , 

&dwValue 

sizeof (dwValue) , 

SdwWriteBytes 



// DWORD dwCode 
// PBYTE pBufln 
// DWORD dwLenln. 
// PBYTE pBufOut 
// DWORD 

// PDWORD 



if (dwValue = 0) { 

break; // we are done 

} 

// decrement SystemBusy counter 

CmdBuf . dwOperationCode = HRADIO_CMD_CLEAR; 

if (I OemlOControl ( 

IOCTL_KAL_RADIO_CNTRL, // DWORD dwCode 



dwLenOut 



pdwActualOut 



& CmdBuf, 
sizeof (CmdBuf) 
NULL, 
0, 

&dwWriteBytes 



// PBYTE pBufln 
// DWORD dwLenln 
// PBYTE pBufOut 
// DWORD 

// PDWORD 



) { 



break; 
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1:1.16 ; 7 Omj^g^Oq^erMons 

OEM_IdIeO is called by the Windows CE kernel when there are no more threads or 
tasks to execute. This function is expected to do a timeout (typically 1 - 5 minutes) 
and if no system activity is detected, the system is shutdown. 

To implement the immediate shutdown feature, this 
function should check HAL_f VideoState flag. If it 
is clear (Video is off) then it does not need to 
do the idle timeout and should shutdown the 
system immediately. 

1.1.17.1 HAL I0CTL Implementation 

BOOL OEMIoControl(DWORD dwIoControiCode, LPVOID IpInBuf, DWORD 
nlnBufSize, 

LPVOID lpOutBuf, DWORD nOutBufSize, LPDWORD 
IpBytesReturned) { 

BOOL retval = FALSE; 

DWORD len; 

DWORD PhysAddr, value; 
PHRADIO_LOCK pHalLock; 
LPHRADIOJREGISTER pHalReg; 
LPHRADIO_FLAG pHalFlag; 

switch (dwIoControiCode) { 
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case I OCTL_HA L_RAD 1 0_CNTRL : 
if (nlnBufSize < sizeof(WORD)) { 
S etLastError(ERROR_IN V A L I D_P A RA METER) ; 
break; 

} 

switch (*(LPWORD)lpInBuf) { 

case HRADIO_CMD_LOCKP AGE : 

if (nlnBufSize < sizeof(HRADIO_LOCK)) { 

SetLastError(ERROR_INSUFFICIENT_BUFFER); 
break; 

} 

pHalLock = (LPHRADIO_LOCK)lpInBuf; 

if (LockPages((LPVOID)pHalLock->dwMemPtr, 1, &PhysAddr, 

2)){ 

memcpy(IpOutBuf, &PhysAddr, sizeof(DWORD)); 
retval = TRUE; 

} 

break; 

case HRADIO_CMD_REGISTER: 

if (nlnBufSize < s izeof(HRA D IO_REGI STER)) { 
SetLastError(ERROR_INSUFFICIENT_BUFFER); 
break; 

} 

pHalReg = (LPHRADIO_REGISTER)lpInBuf; 
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if (pHalReg->Device != 1 && pHa!Reg->Device != 2) { 
SetLastError(ERROR_BAD_DEVICE); 
break; 

} 

if (pHaIReg->Device = 1) { 

REG32(OEM_BASE+RADI01) = UnMapPtr(pHaIReg- 

>dwMemPtr); 

} else { 

REG32(OEM_BASE+RADI02) = UnMapPtr(pHaIReg- 

>dwMemPtr); 

} 

if (!pHalReg->dwMemPtr) { 
retval = TRUE; 
break; 

} 

if (nOutBufSize < sizeof(DWORD)) { 

SetLastError(ERROR_INSUFFICIENT_BUFFER); 
break; 

} 

PhysAddr = pHaIReg->Device = 1 ? (OEM_BASE+RADI01) : 
(OEM_BASE+RADI02); 
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memcpy(lpOutBuf, &PhysAddr, sizeof(DWORD)); 

retval - TRUE; 

break; 

case HRADIO_CMD_FLAG_SET: 

if (nlnBufSize < sizeof(HRADIOJFLAG)) { 

SetLastErrorCERROR_INSUFFICIENT_BUFFER); 
break; 

} 

pHalFlag = (LPHRADIO_FLAG)ipInBuf; 
switch (pHalFIag->wFIag) { 

case HRADIO_FLAG_VIDEO_STATE: 
VideoOffQ; 
break; 

case HRADIOJFLAG_SYSTEMJ3USY: 

// need to increment because multiple devices 

hh-R£G32(OEM_BASE+RADIO_BUSY); 

break; 

} 

retval = TRUE; 
break; 

case HRADIO_CMD FLAG CLEAR: 
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if (nlnBufSize < sizeof(HRADIO_FLAG)) { 

SetLastError(ERROR_INSUFFICIENT_BUFFER); 
break; 

} 

pHalFlag = (LPHRADIO_FLAG)IpInBuf; 
switch (pHalFlag->wFlag) { 

case HRADIO_FLAG_VIDEO_STATE: 

VideoOnO; 

break; 

case HRADIO_FLAG__SYSTEM_BUSY: 

// need to increment because multiple devices 
if (REG32(OEM_BASE+RADIO_BUSY)) { 
-REG32(OEM_BASE+RADIOJBUSY); 

} 

break; 

} 

retval = TRUE; 
break; 

case HRADI 0_C MD_F L A G_GET : 

if (nlnBufSize < sizeof(HRADIO_FLAG)) { 

SetLastError(ERROR_INSUFFICIENT_BUFFER); 
break; 
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} 

if (nOutBufSize < sizeof(DWORD)) { 

SetLastError(ERROR_INSUFFICIENT_BUFFER); 
break; 

} 

pHalFlag = (LPHRADIO_FLAG)lpInBuf; 
value — 0; 

switch (pHalFlag->wFlag) { 

case HRADIOJFLAG_VIDEO_STATE: 

value = (DWORD)REG8(OEM_BASE+VIDEO_OFF); 
break; 

case HRADIO_FLAG_SYSTEM_BUSY: 

value = REG32(OEM_BASE+RADIO_BUSY); 
break; 

} 

memcpy(lpOutBuf, &value, sizeof(DWORD)); 

retval = TRUE; 

break; 

} 

break; 
default: 

SetLastError(ERROR_NOT_SUPPORTED); 
break; 
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} 

return retval; 

} 

1.1.17.2 HAL PowerOn Implementation 

OEMPowerOnO 

if (WakeupSourceO=CompactFlash_RJ) { 

ret = HRADIO_CONTINUE_VIDEO_ON; 
if (RadioWakeupFunction !=NULL) { 

ret = Radio WakeupFunction(HalControlBlock); 

} 

if (ret = HRADIO_CONTINUE_VIDEO_ON) { 
VideoInit(FALSE); 

}.else 

if (ret HRADIO_CONTINUE_VIDEO_OFF) { 
Vidoelnit(TRUE); 

} else 

GotToSleep(); 

1.1.17.3 HAL Changes for LCD 

VideoInit(BOOL KeepVideoOff); 

VideoOnO; 

VideoOfFQ; 
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1 .1 .1 7.4 HAL Considerations for Keyboard 

/* system already running *J 

if ((DWORD)RJEG8(OEM_BASE+VIDEO_OFF)) { 
if (IsWakeupKey(key)) { 
Video(on); 

} 

IgnoreKeyO; 

} 

if (IsPowerDownKey(key)) { 

if (REG32(OEM_BASE+RADIO_BUSY)) { 

VideoOffQ; 

IgnoreKeyO; 
} else ProcessKeyO; 

} 

1.1.17.5 HAL Considerations for Touch Screen 

Same logic as keyboard changes described above. 

1.1.17.6 HAL Considerations for OEM_ldle() 

ifVideoOffO 

GoToSleepO; 
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WHAT IS CLAIMED IS: 

1 . A computer implemented method for receiving 
wireless information on a portable computing device, 
the method comprising : 

powering a wireless receiver only from a 
battery of the portable computing 
device; 

receiving wireless information; 

storing the wireless information in memory 
of the wireless receiver; 

awaking a processor of the portable 
computing device when the wireless 
information fills a threshold of the 
memory available in the wireless 
receiver; and 

transferring the wireless information from 
the memory of the wireless receiver to 
memory of the portable computing 
device . 

2 . The method of claim 1 and further comprising 
analyzing the wireless information received from the 
wireless receiver with the processor of the portable 
computing device. 

3 . The method of claim 2 and further comprising 

powering another component of the portable computing 
device as function of the wireless information 
received. 

4 . The method of claim 3 wherein said another 
component comprises a display. 

5 . The method of claim 4 and further comprising 
powering a keyboard. 

6. The method of claim 4 wherein the step of 
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analyzing comprises analyzing a content of the 
wireless information . 

7. The method of claim 6 wherein the step of 
analyzing comprises analyzing a wireless address 
associated with the wireless information. 

8 . The method of claim 6 wherein the step of 
analyzing comprises analyzing a selected portion of 
the wireless information. 

9. The method of claim 8 wherein the portable 
computing device includes an executable application, 
and wherein the step of analyzing comprises analyzing 
the wireless information as a function of inf ormation 
from the executable application. 

10 . A wireless receiver for use in a portable 
computing device, the wireless receiver comprising: 

a radio receiver for receiving wireless 

information; 
memory for storing the wireless information; 
a processor for analyzing the wireless 

information; and 
wherein the radio receiver, the memory and 

the processor are powered only from 

portable computing device . 

11. The wireless receiver of claim 10 and 
further comprising a controller connected to the 
processor and connectable to a bus of the portable 
computing device. 

12. The wireless receiver of claim 11 wherein 
the memory stores a list of ■ wireless addresses for the 
portable computing device, wherein each address 
corresponds to selected information to be received, 
and wherein each address includes an associated 
operational status entry indicating enablement of the 
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address . 

13. The wireless receiver of claim 12 wherein 
each address in the list of wireless addresses for the 
portable computing device includes a priority status 
entry - indicating if priority messages are received 
thereon . 

14 . A computer implemented method for receiving 
wireless information on a portable computing device, 
wherein the wireless information is transmitted to the 
portable computing device with respect to wireless 
addresses, the method comprising: 

providing a list of wireless addresses on 
the portable computing device, wherein 
each address corresponds to selected 
information to be received, and wherein 
each address includes an associated 
status entry indicating enablement of 
the address; and 

selectively enabling and disabling the 
status entry for the wireless address 
to allow receipt of the corresponding 
information as a function 'of an 
operating parameter of the portable 
computing device. 

15 . The method of claim 14 wherein the step _of 
selectively enabling and disabling includes enabling 
the status entry when the portable computing device is 
powered from a source other than a battery. . . 

16 . The method of claim 14 wherein the portable 
computing device comprises a mobile device . 

17 . A computer implemented method for receiving 
wireless information on a portable computing device, 
the method comprising: 
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receiving wireless information from a 

wireless receiver; 
storing data information in memory 

indicative of the wireless information; 

and 

awaking a processor of the portable 
computing device reading the data 
information in memory indicative of the 
wireless information and powering other 
components of the portable computing 
device as a function of the data 
information. 

18. The method of claim 17 wherein the step of 
awaking ' includes the processor executing a body . of 
code to receive a value indicative of the data 
information . 

19. The method of claim 18 wherein the value 
indicative of the data information includes a first 
value indicating no further processing is needed for 
the wireless information. 

20. The method of claim 19 wherein the value 
indicative of the data information includes a second 
value indicating further processing is needed for the 
wireless information without another component . 

21. The method of claim 19 wherein the value 
indicative of the data information includes a third 
value indicating further processing is needed for the 
wireless information with another component. 
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